In networked systems, Traffic Management services are often used to route requests for resources to service instances (a.k.a. endpoints) that are believed to be near the machines that makes the requests, rather than having the requests traverse the network, in an effort to reduce latency associated with receiving such resources. One example type of a Traffic Management service is based on Domain Name System (DNS). DNS-based Traffic Management reduces latency by serving different DNS responses during the name resolution process that occurs when resources are requested. For instance, when a fully qualified domain name (FQDN) of a service or site is being resolved, a DNS server uses the source address of the machine that makes the request to send a response that references the available endpoint that is believed to be “closest” to the end user, where “closest” is usually defined in terms of network latency.
In conventional networked systems, pings are often used to determine the availability and locations (in terms of latency) of the various endpoints in the networked system. Each ping provides a measure of the round-trip time for a message (e.g., an Internet Control Message Protocol (ICMP) echo request) to be sent to an endpoint and to be received back at the machine that sent the message. These round-trip times may be used to construct a map of the locations of the endpoints. However, this mapping process typically is costly (e.g., requiring latency measurements from millions of locations around the globe), error-prone (e.g., local anomalies in observed latency may be difficult to eliminate), incomplete (e.g., some source addresses may not be measurable), short-lived (e.g., the mapping may change during the time taken to construct the map), and becomes increasingly difficult to obtain and manage as the source address space grows (e.g. IPv6).
Another approach is to utilize a set of geographically diverse “anycast” DNS servers. Using anycast causes each DNS request to be routed to a nearby DNS server that knows its location and assumes that the end user is nearer to it than to each other DNS server. However, the resulting Traffic Management may be compromised if too few DNS server locations are available and/or if a site goes down or becomes unavailable due to connectivity problems. If a site goes down or becomes unavailable, the DNS requests may be handled by other servers, each of which may assume that the end user is “closest” to that server and therefore serve a sub-optimal response.